ALB のメトリクス “ELB 5XXs” は、ロードバランサー側の不具合を示していますか？

Application Load Balancer で "ELB 5XXs" が出ていた時の調査方法を、サポートデスクの実例からご紹介します。

#Amazon EC2

#Application Load Balancer（ALB）

#AWS

M.Shimizu

2022.02.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

最終更新：　2024年1月4日（概念図を追加しました）

こんにちは、テクニカルサポートのShimizuです。

サポートデスクにおいて、Application Load Balancer（ALB）をご利用中のお客様から、よく以下のようなお問い合わせをいただきます。

「ALB の 502 エラー（もしくは 504 エラー）の原因調査で、メトリクスの画面に "ELB 5XXs" が出ていますが、"HTTP 5XXs" は出ていません。これはロードバランサー側（AWS基盤側）に問題があったと判断してよいでしょうか？」

結論から言いますと「いいえ」です。
必ずしもロードバランサー側の問題とは限りません。

筆者のサポートデスクでの経験上、多くの場合バックエンドサーバー側（EC2側）の問題に起因しています。具体的には下記図のような状況です。

どの点を確認すればそう判断できるのか、実際にあったケースをもとに、調査方法をご紹介します。

メトリクスの意味を読み解く

そもそも "ELB 5XXs" と "HTTP 5XXs" は何を意味しているのでしょうか。

AWS の公式ドキュメントには以下の記載があります。

【AWS】Application Load Balancer のメトリクスより抜粋：

HTTPCode_ELB_5XX_Count（= ELB 5XXs）
ロードバランサーから送信される HTTP 5XX サーバーエラーコードの数。この数には、ターゲットによって生成される応答コードは含まれません。

HTTPCode_Target_5XX_Count（= HTTP 5XXs）
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。

上記を踏まえて、冒頭の状況を振り返ると、

「"ELB 5XXs" が出ている = ロードバランサーが500系のサーバーエラーを出している」
「"HTTP 5XXs" が出ていない = ターゲット側（EC2）からは500系のエラーが出ていない」

という意味になるため、ロードバランサーの不具合と考えるのは一見、自然に思われます。

ですが、ここで注意したいのは
「ターゲット側（EC2）から500系のエラーが出ていない = ターゲット側に問題がない」とは言い切れない点です。

「ターゲット側（EC2）の内部で問題が発生して、ロードバランサーへ応答コードを返さなかったため、500系のエラーが何も記録されていない」という可能性もあり得ます。

さらに詳しく調査するには、メトリクスだけではなく ALB のアクセスログも併せて確認する必要があります。次の項で見ていきましょう。

ALB のアクセスログを読み解く

メトリクスの画面で "ELB 5XXs" が出ている日時を特定し、その日時付近の ALB のアクセスログから 502 エラーが出力されている行を抜き出します。
※今回は 502 エラーの例を説明していますが、504 エラーの場合でも同様のため、読み替えてください。

ALB アクセスログの一例：

ここで注視する項目は、8カラム目～10カラム目です。

-1 502 -

それぞれの項目の意味を、AWS の公式ドキュメントで調べてみましょう。

【参考】Application Load Balancer のアクセスログ | AWSより抜粋：

response_processing_time（8カラム目）
ロードバランサーがリクエストをターゲットに送信できない場合、この値は -1 に設定されます。この状況が発生するのは、ターゲットがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。

elb_status_code（9カラム目）
ロードバランサーからの応答のステータスコード。

target_status_code（10カラム目）
ターゲットから応答のステータスコード。この値は、ターゲットへの接続が確立され、ターゲットが応答を送信した場合のみ記録されます。それ以外の場合は、- に設定されます。

これらの意味を上記のログに当てはめてみると、

-1 502 -

「"response_processing_time" が "-1"」→ ターゲット側（EC2）がアイドルタイムアウト前に接続を閉じた
「"elb_status_code" が "502"」→ ALB がステータスコード 502 を返している
「"target_status_code" が "-"」→ ターゲットが応答を返していない

ということが読み取れます。

さら ALB が 502（もしくは 504）エラーを返す理由については、下記の AWS ドキュメントに記載があります。

【参考】Application Load Balancer のトラブルシューティング | AWSより抜粋：

HTTP 502: Bad gateway（一部を抜粋）
ロードバランサーにターゲットへの未処理のリクエストがあるときに、ターゲットが TCP RST または TCP FIN との接続を閉じた。ターゲットのキープアライブ期間がロードバランサーのアイドルタイムアウト値よりも短いことを確認します。

HTTP 504: Gateway Timeout（一部を抜粋）
ロードバランサーはターゲットへの接続を確立したが、アイドルタイムアウト期間が経過する前にターゲットが応答しなかった。

ここまでで確認したことをまとめると、
「バックエンドサーバー（EC2）内部で何らかの問題が発生して、ロードバランサーから送信したリクエストに対して応答を返さず接続を閉じた（もしくはタイムアウトした）ため、ロードバランサー側がステータスコード 502（もしくは 504）を返した」
という状況が推測されます。

冒頭でお伝えした、以下のような状況です。

以上で「"ELB 5XXs" が出ていて、"HTTP 5XXs" は出ていない」という状況が必ずしもロードバランサー側の問題ではなく、バックエンドサーバー側（EC2内部）の問題に起因している理由がご説明できたかと思います。

ロードバランサー側で基盤障害が起きている可能性は？

前項では弊社へのお問い合わせで最も多く見られる事例（ターゲット EC2 側に起因している例）を挙げましたが、状況によってはロードバランサー側に起因している可能性も皆無ではありません。
実際に AWS サポートへ問い合わせて確認すると、稀にですが AWS　基盤側の問題だったケースもあります。

前項でご紹介した調査方法と併せて、以下のような観点も判断基準になります。

500系のエラーが発生する頻度

500系エラーが日常的に発生している場合は、まずターゲット EC2 側の問題を疑いましょう。

ELB は AWS のマネージドサービスであるため、基盤障害がそう頻繁に発生するとは考えにくいです。例えば毎回アクセスが増加する時間帯に500系エラーが出るような場合、EC2　内部のアプリケーション側の問題や、EC2 インスタンスの性能のひっ迫も考えられます。

逆に普段はまったく500系エラーが発生しないのに、ある日突然一度だけ発生した、というような場合は、基盤障害の可能性もあるかもしれません。

500系エラーが発生している範囲

1つの EC2 でのみ500系エラーが発生している場合は、インスタンス側の問題が疑われます。
逆に複数のターゲット EC2 や複数ターゲットグループ、複数アベイラビリティゾーンで同時発生している場合は、基盤障害の可能性も考えられます。

確認方法としては、ALB アクセスログ内で500系エラーの行を抜き出し、ターゲットのIPアドレスから EC2 インスタンスを特定しましょう。
500系エラーが毎回ある特定の EC2　でのみ発生している場合は、ターゲット EC2 側の問題である可能性が高いと言えます。

対処方法は？

ターゲット EC2 側の問題が疑われる場合

対象 EC2 のメトリクスや EC2 内部のアプリケーションログなどを調査して、500系エラーにつながった処理遅延の原因を特定しましょう。

500系エラーが頻発する場合によく見られるケースとして、EC2 内部の Webサーバーの KeepAliveTimeout の設定値が関連している可能性があります。下記ドキュメントを参考に、この設定に問題がないかもチェックしましょう。

【参考】Apache または NGINX を ELB のバックエンドサーバーとして使用する | AWS

また、バックエンド EC2 のリソース不足により処理遅延が発生し、ELB の 504 Timeout エラーにつながる可能性も考えられます。もし EC2 側のCPU不足やメモリ不足が疑われる場合は、必要に応じて EC2 の台数増加、スペック増強も検討しましょう。

ロードバランサー側（AWS 基盤側）の問題が疑われる場合

まずはAWS Health Dashboard を確認し、AWS 側から公開されている障害の情報がないか確認しましょう。

「障害の情報は見つからないものの、ターゲット EC2 側の内部調査でも、どうしても問題が見つからない」という場合は、ALB のアクセスログや調査した内容を添えてサポートへ問い合わせましょう。

おわりに

ALB の 502 や 504 エラーの調査には確認するべき点が多く、弊社サポートデスクにもよくお問い合わせをよくいただくため、「問題箇所がロードバランサー側か、ターゲット EC2 側か」の切り分けに絞った記事を書いてみました。
分かりやすく Yes/No 形式でトラブルシューティングできる記事も書きましたので、皆様の調査のお役に立てば幸いです！

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。